Conversation
| throw new Error("Invalid next player"); | ||
| } | ||
| //if not first move but play on an already played tile | ||
| else if (this._board.TileAt(x, y).Symbol != ' ') { |
There was a problem hiding this comment.
This is an example of content coupling. You're dependent on the boards internal elements
| @@ -0,0 +1,103 @@ | |||
| export class Game { | |||
| private _lastSymbol: string = ' '; | |||
| private _board: Board = new Board(); | |||
There was a problem hiding this comment.
This Game class is coupled to this specific implementation of a Board. By creating the Board class here, we cannot switch out the board for a different implementation.
We could use depenency injection instead, where we pass the Board class to the constructor of Game.
There was a problem hiding this comment.
Injecting/reutilising an element could be a good design decision imo. This allow less tech debt and even a direct monetary return if scaling both classes in Lambdas having different workload. Though it may be interesting to see if Winner would be calling/coupling Board way to much.
|
|
||
| // update game state | ||
| this._lastSymbol = symbol; | ||
| this._board.AddTileAt(symbol, x, y); |
| { | ||
| X: number; | ||
| Y: number; | ||
| Symbol: string; |
There was a problem hiding this comment.
From typscript docs: "Aliasing doesn’t actually create a new type - it creates a new name to refer to that type. Aliasing a primitive is not terribly useful, though it can be used as a form of documentation."
Having to learn a protocol is much cumbersome than having the compiler/IDE help you with the fulfilling of the methods with a type hieracy.
WencesLlobet
left a comment
There was a problem hiding this comment.
If you want to go deeper in the subjects I would suggest on thinking of how the design vocabulary could be applied on serverless functions architechture.
| @@ -0,0 +1,103 @@ | |||
| export class Game { | |||
| private _lastSymbol: string = ' '; | |||
| private _board: Board = new Board(); | |||
There was a problem hiding this comment.
Injecting/reutilising an element could be a good design decision imo. This allow less tech debt and even a direct monetary return if scaling both classes in Lambdas having different workload. Though it may be interesting to see if Winner would be calling/coupling Board way to much.
| { | ||
| X: number; | ||
| Y: number; | ||
| Symbol: string; |
There was a problem hiding this comment.
From typscript docs: "Aliasing doesn’t actually create a new type - it creates a new name to refer to that type. Aliasing a primitive is not terribly useful, though it can be used as a form of documentation."
Having to learn a protocol is much cumbersome than having the compiler/IDE help you with the fulfilling of the methods with a type hieracy.
No description provided.